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REMARKS 

Claims 1-21 are pending in the application. By this amendment, claims 1, 8 and 15 have 
been amended. No new matter is added by these amendments. Applicant respectfully requests 
continued consideration of this application based on the foregoing amendments and the remarks 
urged here. 

35 U.S.C. § 103 Rejections 

The Examiner has rejected claims 1-2 and 8-9 under 35 U.S.C. § 103 as being 
unpatentable over U.S. Patent No. 6,101,531 to Eggleston et al. ("Eggleston") in view of U.S. 
Patent No. 6,038,603 to Joseph ("Joseph") and further in view of U.S. Patent No. 6,473,609 to 
Schwartz et al. ("Schwartz"). In addition, the Examiner has rejected claims 3-7 and 10-14 under 
35 U.S.C. § 103 as being unpatentable over Eggleston, Joseph, and Schwartz in view of U.S. 
Patent No. 6,295,541 to Bodnar et al. ("Bodnar"). The Examiner has additionally rejected claims 
15-21 under 35 U.S.C. § 103 as being unpatentable over Eggleston, Joseph, Schwartz, and 
Bodnar and further in view of U.S. Patent No. 6,317,777 to Skarbo et al. ("Skarbo"). 

Applicant has amended claims 1, 8 and 15 to more particularly point out and distinctly 
claim the inventive subject matter. In particular, claims 1, 8 and 15 have been amended to 
emphasize the inventive concept whereby URLs are used for communication within the device, 
not merely for inter-device communication. Specifically, the URLs in accordance with the 
present invention facilitate proper forwarding of data from applications operating on the device 
to external devices and from external devices to applications operating on the device in a 
seamless manner without the need for application programmers to create custom channels or 
conduits. 

As mentioned in the previous response submitted, a significant problem recognized by 
embodiments of the present invention resides in the difficulty in programming customized 
conduits for the transfer of customized information or data between a handheld device and 
typically a desktop computer. Customized conduits are laborious and difficult ways to customize 
synchronization between two applications, an application resident on the handheld device and an 
application resident on the desktop computer. The above amendments to the claims are meant to 
emphasize this difference from the prior art. 
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Furthermore, as urged in the previous response submitted. Applicant still assert that the 
Examiner's primary reference, Eggleston, is directed to a virtual session manager for maintaining 
a session in a sessionless data communication. Although Eggleston discloses a data exchange 
manager, Apphcant respectfully submits that it does not function in the same manner as the 
exchange manager of the present invention. First, the primary aim in Eggleston is to filter out 
any unwanted electronic mails over expense-bearing networks. There is no such filtering 
required in the exchange manager of the present invention. Any information or data exchange 
between handled computers and desktop computers are not limited or filtered in any such way. 
Applicant respectfully submits that Eggleston fails to disclose or suggest crucial elements of the 
present invention that are recited in the claims. 

On pages 3 and 4 of the office action, the Examiner alleges that Eggleston teaches the 

claimed limitation, "in response to said information, said exchange manager referencing an 

exchange library from a plurality of exchange libraries, wherein said exchange library defines a 

communication protocol for said identified transport mechanism and wherein said exchange 

manager supports a plurality of communication protocols." To satisfy this claimed recitation, the 

Examiner points to disclosure in Eggleston, at col. 5, lines 23-48: 

Both the user's remote communication unit and communication server maintain a 
S&S index containing identifying (summary) information about data which has 
not been fully transferred between the communication unit and communication 
server. As new data is reviewed and filtered for transfer, identifying/summary 
information is captured for any non-qualifying data by either a host unit or the 
communication server. This information is stored in the communication server's 
S&S index, and at least periodically transferred via update messaging to the 
remote communication unit. Upon reviewing its updates or its S&S index, the 
user may send a request for such of the data that it desires partial or full transfers 
or further review. Thus, a cost efficient review mechanism is provided to users for 
determining whether to transfer data that otherwise fails selected filter 
parameters. In a fourth main embodiment, a method and apparatus for optimized 
reply to messaging is provided. When sending a reply, the remote communication 
unit's controller generates a delta (e.g., data representing the content difference 
between two messages) between a preceding message and the reply message, and 
forms an optimized reply using the delta and an identifier of the preceding 
message. On receiving the optimized reply, the communication server uses the 
data unit identifier to retrieve the preceding message from a 
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Applicant respectfully submits that this disclosure does not teach using an exchange library to 

determine how to communication the information, rather it simply teaches the storage and 

tracking of communicated information that has not been fully transferred. 

On page 4 of the Office Action, the Examiner states that "Eggleston does not explicitly 

teach said information having associated therewith a Uniform Resource Locator (URL) 

containing an identified transport mechanism for transmitting said information and also a 

destination for said information" and then chooses to use Joseph to teach aspects of using URL's 

as they are taught by the invention. In the present invention, resident applications on the 

electronic device generate URL's and forward them to the exchange manager to communicate to 

the exchange manager how to transmit the information to an external device. See page 31, lines 

13-20 of the present specification: 

At step 455 an application program 310b accesses one or more records from an 
associated database 365 and exports those records to an exchange manager 350. 
Included in the file for export is an indication, e.g., a command, indicating to the 
exchange manager 350 the mechanism to be used to perform the exporting function, e.g., 
in this case it is synchronization corresponding to library API. Also included is an 
indication of the file type of the data. Other export ., mechanisms include infrared 
beaming (IR), radio frequency (RF), electronic mail (SMTP), file transport (FTP), 
Internet (HTIP), and others. 

Joseph, on the other hand, as is clear from the following quote, teaches inter-device 

communication. See Joseph, col. 3, line 41 - col. 4, line 12: 

Embodiments of the present invention provide a mechanism for generating a URL 
that enables non-standard protocols to be employed in a communications 
network. In accordance with the present invention, computer systems in the 
communications network may be enabled to utilize such a URL. Embodiments of 
the present invention also provide a mechanism for enabling a computer system to 
employ such a URL independent of the capability of the computer system's 
browser to support non-standard protocols. A first computer system may perform 
an operation over a communications network based on a URL. A protocol may be 
employed by the first computer system to access a second computer system over 
the communications network. In order to access the second computer system, the 
first computer system initially determines whether the URL contains a first value 
corresponding to an encapsulating protocol. 

If it is determined that the URL contains a value corresponding to an 
encapsulating protocol, the first computer system determines whether the URL 
identifies an operation protocol. This may be achieved by determining whether 
the URL contains an operation protocol key value indicating that the URL 
contains a value corresponding to an operation protocol. 



Page 9 of 12 



Application No.: 09/598,668 
Reply to Office Action of: March 27, 2008 



If an operation protocol is identified by the uniform resource locator, the first 
computer system selects the operation protocol as the protocol to be employed in 
accessing the second computer system. A computer system may process a URL 
received from a first computer system over a communications network. In 
performing such processing, the computer system determines whether the 
received URL contains a first value corresponding to an operation protocol. 
If the URL contains a first value corresponding to an operation protocol, the 
computer system provides a resource targeted to the first computer system in 
accordance with an encapsulating protocol. The encapsulating protocol is 
identified by a second value in the URL. The resource is provided from a resource 
store that is accessed in accordance with the operation protocol. 

This disclosure in Joseph clearly demonstrates that Joseph does not teach communicating 

information within the electronic device. Joseph describes how some manager might handle the 

information. The concept of a URL in the context of the invention is distinct and not obvious. 

Additionally, on page 5 of the Office Action, the Examiner clearly indicates that: 

Uniform Resource Locator (URL) containing an identified transport mechanism 
for transmitting said information and also a destination for said information, as 
disclosed by Joseph, into the teachings of Eggleston to allow a client via the 
browser uniquely identifying a desired resource by URL (for example, 
"http: //Server A/File Store/File"), which indicates a destination server on which 
the resource is located, the filename, i.e., the location of the resource and the 
appropriate protocol (i.e., "http") to be used in retrieving the desired resource 

Applicant contends that the present invention is not limited by the limitation ''client via the 
browser, " rather this is handled by the exchange manager accessing the exchange library, which 
defines necessary protocols and procedures. 

On page five of the office action Examiner indicates that "Eggleston- Joseph does not 
explicitly teach said file having a data file and a data type, said data type unidentifiable to said 
device external to said handheld device" and introduces Schwartz with reference to col. 6, lines 
36-64: 

It is generally understood that a computing device equipped with an HTML 
browser using HTTP can access hypermedia information in a network server. 
However, HTTP requires considerable computing power and network bandwidth 
resources. For example, a request from a computing device to establish a 
communication session with a network server may require an exchange of a 
number of data packets. In addition to the resources required to implement 
HTTP, significant resources must be supported in the computing device to 
request, format, process and display information. This is not a significant 
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disadvantage in many situations because the computing device, including 
personal computers and workstations coupled to a network operating HTTP, 
generally has sufficient computing power, memory and display capabilities. 
Nevertheless, cellular phone 200 or mobile devices 106 of FIG. I typically do not 
have the computing resources to implement HTTP to run an HTML browser. The 
computing power in cellular phone 200 or mobile devices 106 of FIG. 1 is 
typically less than one percent of a laptop personal computer's computing power, 
the memory capacity is generally less than 128 kilobytes and the graphics display 
capability is very limited. Cellular phone 200 or any of mobile devices 106 of 
FIG. 1 is not a replacement of a desktop computing device or the combination of 
a wireless communication module and a personal computer. Further, making a 
mobile device, such as cellular phone 200, capable of navigating hypermedia 
information in a network server is a significant departure from prior art systems. 

The Examiner further quotes on page 6 of the Office Action: 

The present invention addresses the above described problems and is particularly 
applicable to navigation of Internet web pages by two-way interactive 
communication mobile devices (e.g., mobile computing devices, cellular phones, 
palm-sized computer devices, personal digital assistant devices and Internet 
capable appliance remote controllers) which are capable of wireless 
communication via a link server with service providers or network servers on 
the Internet. Despite the common deficiencies of mobile devices (i.e., a primitive 
processor, little memory and limited graphics capability) which make it 
economically and technically impractical for the mobile devices to operate a local 
browser functioning as if it was in a desktop computer, the present invention 
allows the mobile devices to interact effectively with the Internet and can be used 
with a wide variety of wireless communication networks (e.g., cellular digital 
packet data (CDPD) network. Global System for Mobile Communications (GSM) 
network. Code Division Multiple Access (CDMA) network and Time Division 
Multiple Access (TDMA) network). 
Applicant is unclear how this teaches the generation of a universal file. Applicant respectfully 

submits that Schwartz does not teach the use of a file being generated, but rather teaches a 

method of communication in a more efficient manner by using binary files that are less processor 

intensive that http transport mechanisms. The file, on the other hand, has to be generated and can 

include encryption, none of which are meant to facilitate increased efficiency, but are used for 

their functional advantages in communications. Additionally, in the present invention, the file is 

communicated using the specified protocol in the URL whereas there is no teaching in Schwartz 

of any communication occurring over a diverse set of protocols. 

Therefore, Applicant respectfully submits that any combination of Eggleston, Joseph, 

Schwartz, Bodnar and Skarbo does not teach or suggest every claimed feature of the invention. 



Page 11 of 12 



Application No.: 09/598,668 
Reply to Office Action of: March 27, 2008 



The prior art reference (or references) must teach or suggest all of the claim limitations. In re 
Vaeck, 947 F.2d 488 (Fed. Cir. 1991). Since a prima facie case of obviousness has not been set 
forth. Applicant respectfully submits that independent claims 1, 8 and 15 are allowable over the 
cited references. Claims 2-7, 9-14 and 16-21, by virtue of their dependency on claims 1, 8 and 
15, respectively, are similarly allowable. Early notice to that effect is earnestly solicited. 

Conclusion 

All of the stated grounds of rejection have been properly traversed, accommodated, or 
rendered moot. Applicants therefore respectfully request that the Examiner reconsider all 
presently outstanding rejections, and that they be withdrawn. The Examiner is invited to 
telephone the undersigned representative if an interview might expedite allowance of this 
application. 

Respectfully submitted, 
BERRY & ASSOCIATES P.C. 

Dated: August 27, 2008 Bv: /Reena Kuvper/ 

Reena Kuyper 
Registration No. 33,830 

Berry & Associates P.C. 
9255 Sunset Boulevard, Suite 810 
Los Angeles, CA 90069 
(310) 247-2860 
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